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INFN Requirements for an IPng 
Status of this Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Overview 


This document was submitted to the IETF IPng area in response to RFC 
1550. Publication of this document does not imply acceptance by the 
IPng area of any ideas expressed within. Comments should be 
submitted to the big-internet@munnari.oz.au mailing list. 


Abstract 


This white paper is sent by INFN network team, the Italian National 
Institute for nuclear physics, whose network, named INFNet, is a 
nationwide network founded to provide the access to existing national 
and international HEP laboratory and to facilitate communications 
between the researchers. With this paper we would like to emphasize 
the key points that we would to consider if charged with IPng plan. 
We do not really expect to add original items to the selection, but 
we think that it could be useful to submit the opinions and ideas 
that come from our network experience. 


1. General Requirements 


The problems that are to be solved in IP internet are mainly three: 


1. address exhaustion 
2. flat address space 
3. routing efficiency, flexibility and capacity. 


The aim of IPng study should be to define a plan that solves all 
these problems as a whole and not each of them separately. 


The general requirements that we underline for this transition are: 
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- transparency to the final user: user applications should not be 
influenced. 


- flexibility: Simplify the suitability to new communication 
technology and to topology changes due to new services provided 
or to different users needs. 


2. Application and Transport Level 


Starting from the top of the OSI model, we think that the users 
applications should not be influenced by the migration plan. It 
means that the TCP (the transport layer) must maintain the same 
interfaces and services to the upper layers. Anyway, it is also 
necessary to foresee the use of a different transport services. The 
possibility to use different transport should be offered to the 
applications. Therefore a transport selector field is needed. 


3. Network layer: service and address 


We assume that the network layer must continue to provide the same 
datagram service as IP does. CLNS could be a solution and a reliable 
starting point for the IPng. The main advantage is that this 
solution has been profitable tested and it is already available on 
many systems. It is not, of course, deployed as widely as IPv4 is, 
since it is a newer technology, but it is widely configured and and 
there is already operational experience. The corresponding address, 
the NSAP, is 20 bytes long. It is long enough to scale the future 
data network environment. Its hierarchical format can be organized 
in a really flexible way, satisfying hierarchical routing and policy 
based routing needs and simplifying the distributed administration 
and management. A lot of work has been already done in the majority 
of the countries in order to define NSAP formats satisfying both the 
requirements of administrative delegation and routing performances. 


4. Routing protocols 


We don’t consider the decision about the routing protocol to be 
adopted for the IPng to be fundamental. Even if this choice is very 
important to obtain good performances, the routing protocols can be 
changed or improved at any time, because there is no influence into 
the End Systems configuration. Relationships between NSAP 
aggregation, hierarchical topology and hierarchical routing algorithm 
must be taken into account in IPng plan. These issues could improve 
administration and topological flexibility of the IPng and solve the 
flat problem of the IPv4. The IPng routing protocols should include 
policy-based features. The IPv4 network topology is very complex and 
it will continue to enlarge during the transition. It would be very 
difficult or impossible to manage it without the "policy" tools. The 
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multicast capability as well as any other new features that fit ina 
datagram network should be supported. Regarding the Source Routing 
feature, since we think that it deeply modifies the aim and the 
"philosophy" of a connectionless network and it also introduces an 
heavy complication in the end nodes and routers software, we don’t 
consider it a major issue. 


5. Layer 2 or communication infrastructure media support. 


This is an open field, rapidly changing, then it must be left open to 
any evolution. What it should be recommended is to be compatible with 
the above network layer. 


6. Transition and Deployment 


We faced the problem of the transition of the DECNET global network 
to DECNET/OSI over CLNS. This activity is now proceeding to the last 
step and based on this experience we would underline some points that 
we found important during the transition deployment. The transitions 
must be planned and developed in a distributed way. This means that 
every organization should have the possibility to plan and start 
their network migration without loosing connectivity with the 
existing global internet. Of course, the compatibility with the IPv4 
world must be maintained, this mean that a new generation system must 
interwork with both the IPv4 and IPng nodes, using the same 
applications. 


However, it is important to define a deadline for the backward 
compatibility in order to avoid huge software maintenance in the user 
systems and a "multi-topology" management. We think that a dual 
stack approach could simplify very much the transition, whereas a 
translation mechanism would need a widely and deep coordination in 
order to maintain the global connectivity during the transition 
period. The dual stack is simpler and could be easily developed, but 
it is important to push in order to have pure IPng with global 
connectivity as soon as possible; this could happen when there are no 
more "IPv4 only" hosts. 


Indeed, the drawback of the dual stack configuration is that you 
continue to suffer for the IPv4 address space exhaustion and that you 
must continue to support the IPv4 routing protocols and 
infrastructure. We don’t think that the tunnel solution to 
interconnect the IPv4 isle could give good performances to the users. 
Then, it is important to maintain the IPv4 connectivity and the dual 
stack software support in the End System software in a determined 
timeframe, or the transition will never end. 
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Security Considerations 
Security issues are not discussed in this memo. 
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